No, I think you are right. When I said <But most likely in this case, FIDE first sent out one version and later sent out the other.> I was merely speaking from prior experience. Often FIDE (or any official site) will release a game that's wrong and then soon follow it up with a corrected version. But if your research indicates otherwise, I believe you.

On rare occasions (but not so rare to ignore) the process seems to work backwards, and something that was released correct ends up crazy in later updates.

In the case of Tromsø, we intentionally took the PGN from The Week in Chess instead of the official source. Mark Crowther (of TWIC) tirelessly works on getting the PGN as good as possible before release, and then sometimes makes further changes as required. I don't know if the man is a chess-editing Hercules or if he has a team of elves working for him, but he does incredible work. Much respect. The worse the official source is, the more you can witness his magical abilities.

So that means that we're looking at a data flow like this

FIDE ---> TWIC ---> CG Admins ---> CG Final Product

It's important to note that changes can occur at any one of those nodes. FIDE might change their data, TWIC might change FIDE's data, and CG Admins may change it even further.

<Can I always use the gid to see which game was downloaded first?>

Yes, you can. Games with a lower GID were imported into the database prior to games with a greater GID. Of course it's possible to process rounds out of order and other odd things, and there shouldn't be anything wrong with that, but it's always the case that the lesser GID was in the database first.

<Does <CG> do a "post-production" with an engine to flag games with an final position eval not matching the final result?>

Oh, heavens no. I shouldn't even need to enumerate the problems with that. However it would be really neat to have such games flagged for review. Which brings us to your next question:

<Also - does <CG> automatically flag duplicated games like the two set of pairs above for manual inspection?>

No, but it would be great if it did that.

The programming hurdle looks like this: the function that figures out if a game is a match or not simply returns either 0 (meaning that it's unique) or the GID of the game that is the match. It does a lot of computation to get that answer, but the output is very simple. There is no "degree of confidence", or any way for it to say "I didn't find an exact match, but I did find one that's 98% like it."

Indeed.

I'm still studying it, and am again looking at TWIC games for the Tromso tournament.

(I had the impression that TWIC agreed with FIDE for the Open Section, but I could be wrong. Since I change my code so much I have to do a new, fresh run).

One question I have right now however, is whether or not TWIC supplied the games from the Women's Section?

Maybe I missed them somehow, but I think TWIC only supplied the Open Section.

Do you know?

* * * * *

Ack!

TWIC does include the FIDE id for all colors for some of the games (171 if my program is working right) for Tromso wolm.

<E.g.

[Event "41st Olympiad Women 2014"]
[Site "Tromso NOR"]
[Date "2014.08.02"]
[Round "1.62"]
[Board "4"]
[White "Ralivololona Hanitriniaina, Andri Hanitriniaini"] [Black "Machlik, Edit"]
[Result "0-1"]
[BlackElo "1950"]
[ECO "B13"]
[Opening "Caro-Kann"]
[Variation "exchange variation"]
[WhiteTeam "Madagascar"]
[BlackTeam "Norway 2"]
[BlackFideId "1513591"]
[EventDate "2014.08.02"] >

He's got every tag but the kitchen sink... and <WhiteFideId>.

These kinds of inconsistencies are a major headache - I really need some part of the system stable in order to bootstrap.

Well, not really, but it's making the code increasing Ptolemaic in its error handling...

http://upload.wikimedia.org/wikiped...

(I'm not sure if I brought it up before, but if I did, apologies in advance).

Is it possible for <CG> to order a player's games not just by year, by also by Event/Site field as well?

In other words, can all the player's games from the same event be grouped together?

Can <CG> possibly normalize the Site tag for the <Sinquefield> pgn?

Here's what it gives currently (after R3):

<[Event "0:08:33-0:04:33"]>

<[Event "Saint Louis USA"]> x 5

<[Event "0:03:33-0:05:33"]>

<[Event "Saint Louis USA"]> x 2

<[Event "St. Louis USA"]>

Also the player's names, <CG> is supplying the games with multiple versions in the PGN:

e.g.

<
Aronian | L Aronian | Levon Aronian

Carlsen | Magnus Carlsen

Caruana | Fabiano Caruana

Hi Nakamura | Hikaru Nakamura

Maxime Vachier-Lagrave | Vachier Lagrave,M

V Topalov | Veselin Topalov
>

<Do you know Mark?> We've exchanged emails on a few occasions.

<Is it possible for <CG> to order a player's games not just by year, by also by Event/Site field as well?> They should be, but if it was really easy to do that we would have done it long ago. It's not a huge technical challenge to make it work, but to make it work really quickly will take finesse. It will require changes to SQL statements and some major re-indexing of our tables.

<Can <CG> possibly normalize the Site tag for the <Sinquefield> pgn?> This is a nuance that is probably new to you. Here's the situation:

During live broadcasts, the clock information is stuffed into the PGN. Since there are no widely accepted fields for "how much time white has / how much time black has" it has become a de facto practice to stuff that information into, of all things, the site field. So at the end of one of our live games, invariably we end up with a site that looks like <0:08:33-0:04:33>. (You'll notice it always has 33 seconds for both players. There's a story behind that as well, but I'll save it for another day.)

Fortunately we have written a program that identifies such data and replaces it with what it should be (it does this simply by looking for other site tags in the same tournament that aren't clock times.) In the rare occasion when it finds a discrepancy (two different site tags for the same event) an admin has to review the situation. For example "Linares/Morelia" from a few years back required manual fixing.

So I just ran the software at your request, but expect to see that kind of data slip into the games during the tournament. When it's over, we'll run it one last time to rid ourselves of the remaining mangled site tags.

In a perfect world the live-game-broadcasting software would know what to do when the game was over, and made that timestamp only show up while the game is in progress.

<Also the player's names, <CG> is supplying the games with multiple versions in the PGN> You are witnessing what the official site is producing--one run of fixpgn and it will all be normalized.

I think, the opening classification is wrong.

K Arakhamia-Grant vs V Da Vilhete, 2014

Both <CG> and <TWIC> have this as a 33-move win for White.

<FIDE>'s official link gives it as a 7-move win for White.

https://d16lfcqjkxdsjm.cloudfront.n...

Pretty clear which result is correct, <TWIC>'s (assuming <CG> is following <TWIC> - it doesn't really get an independent vote). There is no way the game ended at move 7.

Now the question - how is it that <TWIC> got the correct score while <FIDE>'s site didn't?

1) Maybe Mark gets e-mailed the scores from the players themselves?

If so, it would be nice to have this information somehow noted. It would also be nice if the results could be forwarded to FIDE itself, in order to correct the record. FIDE really should be the authority for these games after all.

2) Maybe Mark has a special connection with <FIDE>, and they give him a different version than what they publish.

The obvious implication here is that <FIDE> really should correct the scores for both the public and <TWIC> if this were the case.

3) FIDE once had the correct version of the game in an earlier zip-file, which <CG> and <TWIC> downloaded. Later, the zip-file got corrupted (or somehow updated with a corrupt/truncated version of the pgn).

<This is a tedius but rewarding project.>

On the same page (Chessgames Editor Guide) -

<To remedy this daunting problem, the tireless efforts of our Chessgames Editors sort matters out using a powerful three-step process that we call "Tournment Induction":>

- maybe calling it "Tournament Induction" would be better...

< Please describe you skills and resources as a chess historian, database expert, etc. >