Members · Prefs · Laboratory · Collections · Openings · Endgames · Sacrifices · History · Search Kibitzing · Kibitzer's Café · Chessforums · Tournament Index · Players · Kibitzing User Profile Chessforum

CG Librarian
Member since May-07-11 · Last seen Apr-20-15
<"I adjust">

Hi, I'm your friendly Chessgames database librarian. My job is to make the database better by processing correction slips.

I'll be using this forum to ask for help when something needs more research. You can use this forum for the same purpose, to get others' input on possible errors or duplicates.

If you've submitted a correction there's no need to post here about it. I will see the correction slip and it will be fixed as soon as possible. Thanks!

A few notes:

1. As you probably know, there's currently a long backlog of corrections. From now on, new corrections will get priority, while I also chip away at the older ones. If you submit a new slip on something that isn't fixed yet, that will bump it up to the top and it will get fixed faster. Please be judicious about this.

2. Probably due to the backlog, volunteer bio editors have started to put "aka" and a duplicate player link in bios. Please don't do this, just submit a correction slip. Similarly, if there's a problem with a player name (such as first and last name reversed), submit a slip on it rather than putting it in the bio, so it can get changed in the database.

3. We also try to delete kibitzes about errors that would be confusing once the error is fixed, so the more you keep the corrections to the correction slip, the less extra work for me and the faster I can correct the database. Full Member

   CG Librarian has kibitzed 21 times to chessgames   [more...]
   Jun-04-12 CG Librarian chessforum (replies)
CG Librarian: OK, here are a few things I wanted to mention: 1. I got a copy of Chess Personalia (quite a while ago now) :) 2. The reason CG put a hyphen in Spanish double last names was so the database software didn't get confused about what the last name was (for things like the Player ...
   Nov-03-11 European Team Championship (2011) (replies)
CG Librarian: <Slaven MNE> You're right. We also had the wrong Georgiev. I think the error must have gotten propagated from the official site.
   Aug-08-11 World Junior Championships (2011) (replies)
CG Librarian: Here's the situation with incorrect game scores for this tournament: we first received many truncated games, then the correct versions. I've removed all the incorrect duplicate games that affect the leaderboards. If you see more please submit a correction slip on them.
   May-28-11 World Championship Candidates Final (2011) (replies)
CG Librarian: <alexmagnus: Actually if you do the search now you get +9 -5 =27. One Gelfand win from 1990s, present just a week ago, now magically disappeared... Maybe it was attributed to some different players.> Hello, I just saw this. The stats changed because I merged away a ...
   May-08-11 chessforum (replies)
CG Librarian: <Domdaniel: Welcome, o Eager and Bright database administrator person.> Thanks, and hello everyone! My chessforum is now available for correction-related comments. I'm sure I'll also be posting things that need additional research, so check back often.
(replies) indicates a reply to the comment.

Kibitzer's Corner
< Earlier Kibitzing  · PAGE 17 OF 17 ·  Later Kibitzing>
Premium Chessgames Member
  zanzibar: Thanks <Phony>.

I understand the cautions - after all, as you point out, there's no assurance that the "official" Berger tables were used for historical tournaments.

In fact, I started my recent explorations using the wiki algorithm - which is much easier to implement than the FIDE algorithm. So yes indeed, there's many a possible table for a RR.

* * * * *

Also, I was wrong about byes losing information. For an individual round, that's true. But as you point out, the players have a color asymmetry over the entire tournament which can be used to give the color of bye.

* * * * *

I'm trying to solve the general case, where an entire tournament is scheduled with the FIDE Berger tables(*) but none of the games have a round number.

Can the games be sorted into rounds?

It's just a challenge for some idle moments, but I think it might be fun to try to crack.

I'm trying to do it heuristically, of course, and not formally (via mathematical proof).

Right now it looks like it might be possible to solve by looking at color correlations. Isn't it true that players 1 and N can be identified as having the most games with the same color.

That's about as far as I've gotten.

* * * * *

(*) By the way, I wonder if the USCF uses a variant of the Berger tables. I see mention of Cranshaw-Berger and Porter-Cranshaw-Berger tables.

I should check out the USCF Official Rules book from the library.

Premium Chessgames Member
  Phony Benoni: <zanzibar> In the Standard Berger tables, if "N" is the total number of players and there is an even number overall:

(1) Player 1 through N/2 start with white and receive an extra White overall. Player N/2 always alternates, while the others get two Whites in a row at some point.

(2) Players (n/2)+1 through N start with Black, and get an extra Black overall. Player N always alternates, while the others get two Blacks in a row at some point.

So, in a 16-player tournament, #1-8 get an extra White, and #8 always alternate; #9-16 get an extra Black, and #16 always alternates.

I dealt mostly with older tournaments such as the USSR Championships which used Standard Berger, and haven't looked at other systems.

I am sure this should be easily programmable, at least in principle. Dealing with variations, of co8urse, would complicate matters.

Premium Chessgames Member
  zanzibar: I have to admit this is a little tougher than I first thought!

Thanks for the pointers... clearly I have some homework to do.

Premium Chessgames Member
  zanzibar: There's a series of 10-RR's from <Margate (1935-1939)>.

They seem to all use a non-standard (i.e. non-Berger) scheduling table for the 10-players.

For instance, there is one player who gets 2w, 2b, 2w, 3b for colors. All the other players get the more usual alternating colors with maybe one repeat.

Using this unique player as player one allows enumeration of the other players. From then I determined this pairing-schedule:


Margate = {

1: [ (1,10), (5,6), (7,4), (3,8), (9,2) ],

2: [ (1,2), (4,9), (6,7), (8,5), (10,3) ],

3: [ (3,1), (2,4), (5,10), (9,6), (7,8) ],

4: [ (4,1), (3,5), (6,2), (8,9), (10,7) ],

5: [ (1,5), (2,8), (7,3), (4,6), (9,10) ],

6: [ (1,6), (3,9), (5,7), (8,4), (10,2) ],

7: [ (7,1), (2,3), (4,10), (6,8), (9,5) ],

8: [ (8,1), (3,4), (5,2), (7,9), (10,6) ],

9: [ (9,1), (2,7), (4,5), (6,3), (8,10) ]



* * * * *

Does anybody have experience with this kind of table? Is their a better presentation (enumeration) which makes the pattern more obvious?

I'm wondering how to generalize this schedule for an arbitrary number of players.

Premium Chessgames Member
  Phony Benoni: <zanzibar> Seeing that reminds me of something.

Back in the days when I played in Speed tournaments (yes, that long ago), we had a simple system for making pairings quickly. One player, the pivot, was seated in a corner of the table and never moved. The other players, after each round, would move one seat to the right. If they reached the pivot chair, they would go around the corner the to first seat on the other side.

So the movement looked like this (Player #1 is the pivot):

<Round 1>
1 2 3 4 5
10 9 8 7 6

<Round 2>
1 3 4 5 6
2 10 9 8 7

<Round 3>
1 4 5 6 7
3 2 10 9 8

<Round 4>
1 5 6 7 8
4 3 2 10 9

<Round 5>
1 6 7 8 9
5 4 3 2 10

<Round 6>
1 7 8 9 10
6 5 4 3 2

<Round 7>
1 8 9 10 2
7 6 5 4 3

<Round 8>
1 9 10 2 3
8 7 6 5 4

<Round 9>
1 10 2 3 4
9 8 7 6 5

Which duplicates your Margate observation.

Now, there must be some pattern to the color allocation I haven't figured out yet. OUr speed tournaments were generally double round robin, so that didn't matter. But this is a quick and uncomplicated alternative way to determine the basic pairings

Premium Chessgames Member
  zanzibar: <Phony> very good work. Yes, that is the pattern.

I missed it, properly because of the non-standard color pattern.

With you observation I think I can generalize the pattern as follows:

Player 1 is the pivot, players are numbered clockwise (cw) and rotate counter-clockwise (ccw).

Player 1's colors are 2w, 2b, 2w, ...., 2w, 3b

For all other tables, colors are flipped for each round for every other table (always the same tables, e.g. table's 2 and 4: e.g. R1 (9,2) & (7,4), R2 (10,3) & (8,5), etc.)

Now, the question is, besides Margate, are there other tournaments utilizing Table 1 pivoting?

Aug-10-15  RonB52734: <zanzibar> <Mr. Benoni> This looks not unlike the way duplicate bridge tournaments are handled.
Premium Chessgames Member
  offramp: Duplicate post detected!
Premium Chessgames Member
  technical draw: Yes but the post was vulnerable.
Premium Chessgames Member
  TheFocus: I tried to hire a librarian. Unfortunately, they're all booked.
Aug-15-15  crawfb5: So you had to settle for a page?
Premium Chessgames Member
  TheFocus: Yes, a delightful young lady named Paige!
Premium Chessgames Member
  zanzibar: OK, this is technical, so I'll put it here.

How to handle <Vienna (1873)>?

Well, the games must go into a standard PGN, with stubs for the forfeited games. But the scores there don't reflect the scoring actually used in the tournament.

Each pairing is a best of three match. That is, at most three games played, where a match is won with two decisive game wins.

On the other hand, a match can be drawn by 1/2-1/2-1/2 or any 0-1-1/2 permutations.

The rounds are notated as Rn.m where n runs over the pairings (1-11), and m over the match games (1-3).

A won match is scored as one point, a drawn match by 1/2.

So, given the games, I just created a stub for each match pairing. The color used mirrors the first game in a match colors.

The stub comment then records the match record of whoever is White. Black's scoring is simply the compliment. The actual individual games have the usual alternating colors, in the modern style.

I'll show even more details in a blog post later.

Premium Chessgames Member

click for larger view

Premium Chessgames Member
  zanzibar: <chessgame901> a beautiful way to end the game!
Premium Chessgames Member
  AylerKupp: <CG Librarian> I'm trying to build a database from *.PGN files (isn't everyone?) and I came across your forum as I was searching for means to detect and delete duplicate games from a database. If you are still active, how do you do that? Do you have an algorithm you use or is there a freeware/shareware program available to do that? If there is, how reliable is it?

I also want to have the database contain only games played at classical or near-classical time controls under "normal" competitive circumstances. I've used the [Event field to filter out games containing the keywords "Blitz", "Rapid", "Blind", Exhibit", "Off-Hand", etc. I've also looked at well-known event names like "Amber", "ICCF", etc. Do you have a list of keywords or event names that you could share to make sure that I am not missing any obvious one?


Premium Chessgames Member
  zanzibar: <AK> Still there?

I'm not the Librarian, but I did stay in a Holiday Inn last night....

I use SCID's <Delete Twin> feature.

Do you use SCID? If not you should, if only for this feature. Very powerful, and flexible.

Some other words for your exclude filter are "casual" and "corr". And any game involving NN maybe?


Premium Chessgames Member
  zanzibar: I'm going to move the SCID reboot discussion here... at least for a couple of posts.

I've managed to crack some of the coding aspects - even though I don't really do TCL/TK coding (though I did some Tkinter stuff awhile ago).

The code base is written in C++ and Tcl. The project is pseudo-orphaned, as neither Shane Hudson nor Pascal Georges are currently active. There are new versions put out - but v4.5 wrecked the xtab features which I depend on, and v4.6 seems aimed at making the interface look more and more mobile-phone like.

v4.5 also added the feature of *not* reusing the gamelist window - which I find very inconvenient as I constantly shift from one database to another while working (so - best to just show me the current db's gamelist in the one gamelist window - like v4.4 and before).

So, my choice was to fork off v4.4. The one disadvantage is that v4.5's gamelist window allows sorting on columns - so I might have to retrofit those code changes.

My original work in upgrading the player bios involved a few simple hacks to scid.gui - which is the Tcl component.

Let me mention that this one piece of code involves ~100k lines of code. It's huge. Luckily I could just find the German DSB and VIAF pieces and copy/modify them.

Tonight I tried to streamline the code a little too - as it mixed base64-encoded image data with the useful code. For me, I generally like factorizing the code and data - plus having all that base64 ASCII encoded data constantly interfered with simple text searches.

So tonight I split scid.gui into the TCL program + a TCL adjunct file with the photo image data. That make scid.gui a manageable ~60k lines of code, with a ~40k file.

I don't know how much of the effort I'll document here - I suspect the interest is too low. A bit of a shame, as I feel this could be (is) very, very useful stuff - getting a lot of mileage out of a just a little effort. So, stubborn old goat I am, I'll try to document the effort a little here, partially in the hope of getting a little help if others choose to engage.

Premium Chessgames Member
  zanzibar: I looked a little more at SCID's code structure. All the TCL files are merged into scid.gui (for windows), which loses the directory structure (which offers at least a little guidance to the code structure).

That means that my splitting out the data components might need some rethinking. If it were a Python project - the use of modules would be strongly recommended. At the moment my TCL languages skills are just a little better than my Russian language skills - so I should punt for now.

Still, in modifying the behavior I'm doing a lot of small edits to scid.gui directly.

Here's some changes I've instituted:

1) Player Finder listing now defaults to 500, up from 50.

2) The Player Info window is once more auto-raised on updating (say with a new player). Not sure why this got commented out at some point in the past.

3) The Player Finder window now gray highlights any selected player on mouse-click. Seems more natural. (It still yellow highlights on mouseover).

4) Player Rating Graph windows are auto-raised on update.

5) Default for Insert Mark color in Comment Editor changed to dark blue (from red).

(A personal preference of mine - should be some kind of option. I'm thinking of changing the colors in the rating graphs to match EDO as well - but this might be wandering off into the weeds).

6) Import PGN Window now allows a raw FEN string as input.

I got this idea from <ChessTempo>'s input window - which allows normal PGN and raw FEN input. Very convenient. I use this a lot, and previously had to use the more cumbersome SCID: setup board.

7) Of course the bio data changes, %EDO, %CG, %WIKI and %Edo.

Premium Chessgames Member
  zanzibar: <SCID>'s piece graphics can look kinda bad for some of the pieces.

My standard version is 4.4 (since they broke some of the xtab features in later version, and for other reasons). It provides these pieces:

<Alpha, Brauhaus, Eboard, Fantasy, Fantasy2, Kingdom, Leipzig, Merida, Merida1, Merida2, USCF, Blind>

Only a subset of these are truly visually up to snuff. E.g. Alpha, a very good design, has some annoying white random speckle pixels on the outlines of the pieces.

And some others have jagged edges (i.e. random pixelation noticeable on the edges), which we've come to not accept in this post-W95 world.

I often wondered what was going on, as the resolutions should have yielded better results.

Having implemented my own version - the reason has become clear to me.

The best piece design requires image blending of the piece image and background image. Where a boundary pixel can specify an alpha-value for blending.

So, a good high-resolution piece image isn't enough. It must also allow alpha-channel blending.

And that requires PNG images.

(Which is why Merida1 and Fantasy look good, no matter what background is selected (well, for most backgrounds anyways)).

Premium Chessgames Member
  zanzibar: How would you notate 1.Qb4xb5?

click for larger view

1r5k /8/8/1q6/1Q6/8/8/1K3Q1r w - - 0 1

How about the different queen captures here:

click for larger view

1r5k /1Q6/8/1q6/1Q6/8/8/1K3Q1r w - - 0 1

And here:

click for larger view

1r4k1 /1Q6/8/8/1Q2q2Q/8/8/rQ2K2Q w - - 0 1

(SCID actually gets at least one of them wrong in the last example)

Premium Chessgames Member
  zanzibar: <pgn-extract> has been a program I've relied on when writing UCI routines - as engines tend to speak LAN format, and most PGN uses SAN format.

Interestingly, pgn-extract is still being updated, with this important very recent addition:


21st July 2017: Added --nobadresults to suppress games with inconsistent result indications. Fixed failure to correct terminating result with --fixresulttags. <Added --allownullmoves.>


Trying to write a program which understands PGN SAN input, let alone PGN SAN output is quite a challenge, at least in my experience.

<( SAN = short algebraic
__ LAN = long  algebraic )>

Premium Chessgames Member

Premium Chessgames Member
  zanzibar: Are there any TCL/TK programmers out there?

I'm almost ready to unveil my 4.4/4.5 merged/improved version of SCID. There are some improvements which are just hacked in - and I'd really appreciate some review/improvement of the mods.

Here's a list of some of the changes - in reverse order:

1) Gamelist is now a hybrid of 4.4 and 4.5.

- Unlike 4.5, only one gamelist (or gameslist) window is used. Much less confussing.

- The 4.5 sorting features are fully implemented - which is a big improvement, perhaps the best feature of 4.5.

2) PNG piece sets have been introduced.

- Alpha, Eboard, and Leipzig all now look like they should, without speckling, or jagged edges.

- Merida2 has been modified to use pure White.

3) FEN input can be given in the PGN input window, as a convenience.

4) Biographical player pages can now allow direct linking to CG, EDO, and Wiki pages.

5) Rating graphs for historical players, using EDOchess ratings, are available for Z-base players.

6) Photographs for almost all Z-base players are now available. Biographies as well.

Premium Chessgames Member
  zanzibar: Poor old SCID - semi-orphaned since first Shane left, then Pascal.

The code base left behind isn't being keep coherent - as developers modify it for improvements in one area, while breaking sections of the code in others.

Case in point - the xtab treatment, which is why I stayed with 4.4.

But there's some other revealing glitches.

First of all, tcscid.exe isn't distributed with the binary kits. This is really a very important component of SCID - if only for having a tool used to run SCID by hand for debugging.

In principle, it also allows for TCL scripts to be written for automated processing of DB's in various ways as well.

Well, the source code package can be used to build it - but one has to go find the from some other source than the official sourceforge distribution.

Then there's this - all the documentation for tcscid, which is really fundamental documentation about SCID's underlying code - is written for v3.2.

Now, I've released it in reformatted form with backlinks. But comparing v4.3, v4.4, v4.5 I see that tcscid is a moving target, and lots of changes (both additions and subtractions) have gone undocumented.

It seems that Shane was the last person to keep the documentation synched with the code - even Pascal omitted documenting a number of sc_tree sub-commands.

(In fact, one of the problems I'm having with retrofitting the GamesList window is that the sc_filter command has changed so much between version 4.4 and 4.5 - without explicit being documented.)

I've gone through at least noting the changes, and will release a new version of the documentation soon.

And for the road, one last example.

There was a function - <sc_base ecoStats>, which was supposed to print out ECO opening statistics for games in a db. I couldn't get it to work.

Why not?

Well, I had to muck around with the C++ code in the debugger to find that there was an undocumented option to the open command:

<sc_base open [-readonly] [-fast] <db>>

It turns out that the ECO stats weren't being updated if fast opens were used. One can understand that fast opens might be desirable - for speed and memory usage. Maybe it should even be the default.

In fact, it is the default. Trouble is, there's no <-slow> option. Clearly someone just changed the default without realizing how it might negatively impact tcscid.

Suffice it to say that the z-version will have a <-slow> option.

Jump to page #   (enter # from 1 to 17)
search thread:   
< Earlier Kibitzing  · PAGE 17 OF 17 ·  Later Kibitzing>
NOTE: You need to pick a username and password to post a reply. Getting your account takes less than a minute, totally anonymous, and 100% free--plus, it entitles you to features otherwise unavailable. Pick your username now and join the chessgames community!
If you already have an account, you should login now.
Please observe our posting guidelines:
  1. No obscene, racist, sexist, or profane language.
  2. No spamming, advertising, or duplicating posts.
  3. No personal attacks against other members.
  4. Nothing in violation of United States law.
  5. No posting personal information of members.
Blow the Whistle See something that violates our rules? Blow the whistle and inform an administrator.

NOTE: Keep all discussion on the topic of this page. This forum is for this specific user and nothing else. If you want to discuss chess in general, or this site, you might try the Kibitzer's Café.
Messages posted by Chessgames members do not necessarily represent the views of, its employees, or sponsors.

You are not logged in to
If you need an account, register now;
it's quick, anonymous, and free!
If you already have an account, click here to sign-in.

View another user profile:

home | about | login | logout | F.A.Q. | your profile | preferences | Premium Membership | Kibitzer's Café | Biographer's Bistro | new kibitzing | chessforums | Tournament Index | Player Directory | Notable Games | World Chess Championships | Opening Explorer | Guess the Move | Game Collections | ChessBookie Game | Chessgames Challenge | Store | privacy notice | contact us
Copyright 2001-2018, Chessgames Services LLC