When I got back from the club, I decided to add to the per competitor information a list of the zones worked, to compliment the list of large squares worked. I was surprised to find that some people has zone 14 listed twice. Zone 14 is by far the most common zone so it would be the one most likely to show a problem.
In my code I was encoding the zone as a string rather than a number. There were reasons why this made sense in the early evolution of the code. However this meant that the code was sensitive to the *exact* text in file observers.txt., including the presence of spaces. What I had thought I had done, but regrettable has not done correctly, was to strip the white space out making the code whitespace insensitive. However the way that I had written the code made any observer entry with different whitespace to the others in that zone appear to the program to be a different zone. The same error applied to entities (countries).
For example:
G3XYZ, 14, 223
and
G3ABC, 14, 223
would look like two different zones and BTW two different entities due to the white space error in the file observers.txt.
This may account for why the results changed when I needed to recreate a large part of the observers.txt file a few days ago, and why there may have been some day to day changes as I edited the file to add new observers.
For those interested I ran the following code on the observers file:
of = open(‘observers.txt’, ‘r’)
for o in of:
od = o.split(‘,’)
if str(int(od[1].rstrip()))==’14’ and od[1].rstrip()!=’ 14′:
print “The old method”
print o
print “Try the new method”
if str(int(od[1].rstrip())) == ’14’:
print “New method works”
else:
print “New method also fails”
print “=========”
and I got the following result:
The old method
PH0WAW, 14, 263
Try the new method
New method works
=========
The old method
PH2LB, 14, 263
Try the new method
New method works
=========
Thus anyone who worked either of these stations would have got a double credit for zone 14.
I randomly tested zone 5 and found one entry in error.
The code “str(int(od[1].rstrip())” is a clumsy but robust way of dealing with the problem, so hopefully that is one more problem removed from the code. Of course I also corrected the same problem in reading the country column in the observers.txt file.
The code and the observers.txt file are viewable by anyone and any review of the work is appreciated.
The overall effect on the scores I published this morning can be seen by comparing the new result:
Posn Member CQscore MHscore
1 GX3WSC 5664 11564
2 M0WID 2934 5705
3 G3RMK 2448 4590
4 G3YSX 2370 4740
5 M0TZZ 2304 4176
6 G3NZP 793 1464
7 G4PEO 700 1400
8 G0KCH 546 1092
9 G4FYY 456 1140
10 G4ANN 320 704
11 G4PFW 204 408
12 M0HQM 138 345
13 G3VJM 96 192
14 G7OBF 22 44
15 VK6PG 12 18
with the result I published this morning:
Posn Member CQscore MHscore
1 GX3WSC 6399 11613
2 M0WID 3116 5740
3 G3RMK 2601 4590
4 G3YSX 2544 4770
5 M0TZZ 2448 4176
6 G3NZP 854 1464
7 G4PEO 700 1400
8 G0KCH 624 1092
9 G4FYY 456 1140
10 G4ANN 320 704
11 G4PFW 204 408
12 M0HQM 138 345
13 G3VJM 120 192
14 G7OBF 22 44
15 VK6PG 12 18
Thus most people have lost points, but the relative positions are unchanged.
73
Stewart/G3YSX