ericek111/Nonemm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clear the stale items out of the docs

Browse Source 
The scoring audit says which of its findings are fixed and which are still
open, its line numbers point at where the code is now, and the order of what
to do next is what is left rather than what is done.

In unfinished.md: Send All was listed as missing 500 lines above the section
that describes it, three TypeAhead methods had been renamed, the station
number clash is guarded and the paragraph saying it is not was next to the one
saying it is, and the registry holds twenty-six contests rather than
twenty-five. The claim that every instance of the station's logs scores
contact for contact is replaced by what the replay of 2026-09-06 actually
found.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0157i7PiZyqBkquxS9A6FTdQ
This commit is contained in:
erikbrocko
2026-09-11 07:51:45 +00:00
co-authored by Claude Opus 5
parent b5d9f1e21c
commit dae1f4f197
2 changed files with 40 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/scoring-audit-2026-09-06.md
+13 -11
View File
@@ -1,6 +1,8 @@
Scoring and N1MM compatibility review, 2026-09-06. Code reviewed: `6e24e00`.
**Nonemm does not yet match N1MM Logger+ well enough to claim general contest compatibility.** Many ordinary QSOs agree, including large WPX and WAE logs, but there are confirmed failures in entry completion, excluded QSOs, exports, and several contest rules. This review changes documentation only.
**Nonemm does not yet match N1MM Logger+ well enough to claim general contest compatibility.** Many ordinary QSOs agree, including large WPX and WAE logs, but there are confirmed failures in entry completion, excluded QSOs, exports, and several contest rules. This review changed documentation only.
**Status on 2026-09-10.** Findings 1, 2, 3, 4 and 7 are fixed, each with tests, and finding 14 turned out to be what N1MM does. Findings 5, 6, 8, 9, 10, 11, 12 and 13 are open. The fix notes sit under the findings themselves; the numbering and the original text are kept so a finding can be looked up by its number.
The review covered the shared scoring engine, the 26 built-in contest families, contest-name resolution, selected UDC implementation paths, entry completion, score display, storage updates and Cabrillo generation. Specific behavior was compared with the local decompiled N1MM reference and published sponsor rules. N1MM was not executed. This is not a certification of every feature, contest category, UDC option or historical rule version.
@@ -40,27 +42,27 @@ Notable examples: all six WAE RTTY instances matched every compared field. Field
5. **P1 — BARTG HF and Sprint are merged into one incompatible definition.** [BartgSprint.cs](../src/Nonemm.Contests/Rules/BartgSprint.cs) uses report, serial and time, and countries/areas per band, but advertises `BARTGRTTYS` and `BARTG-SPRINT`. [N1mmContestNames.cs](../src/Nonemm.Contests/N1mmContestNames.cs) also maps `BARTGSRTTY` to this class. N1MM has separate `CBARTGSpring` and `CBARTGSprint` classes. The January Sprint exchanges a serial only and counts countries/areas once across bands, as specified in the [BARTG Sprint rules](https://bartg.org.uk/wp-content/uploads/2025/05/bartg-sprint-rules-2025-v3.pdf). Split the definitions and preserve each one's identity, exchange, multiplier scope and export format. Agreement on the supplied March HF log does not validate Sprint support.
6. **P2 — ARRL 10M uses the wrong state multiplier list.** [Arrl10Metre.cs](../src/Nonemm.Contests/Rules/Arrl10Metre.cs), line 49, uses the ARRL DX list. A Mexican `JAL` exchange became country multiplier `XE`; another Mexican state would therefore not add its own multiplier. The code also lacks the contest's maritime ITU-region multiplier treatment, and its send-state decision omits Alaska and Hawaii. Use the actual 10M rules and [ARRL's 32 Mexican multipliers](https://contests.arrl.org/contestmultipliers.php?a=xe), rather than sharing the ARRL DX eligibility list.
6. **P2 — ARRL 10M uses the wrong state multiplier list.** [Arrl10Metre.cs](../src/Nonemm.Contests/Rules/Arrl10Metre.cs), line 69, uses the ARRL DX list. A Mexican `JAL` exchange became country multiplier `XE`; another Mexican state would therefore not add its own multiplier. The code also lacks the contest's maritime ITU-region multiplier treatment, and its send-state decision omits Alaska and Hawaii. Use the actual 10M rules and [ARRL's 32 Mexican multipliers](https://contests.arrl.org/contestmultipliers.php?a=xe), rather than sharing the ARRL DX eligibility list.
7. **P2 — Oceania undercounts 15M and 10M.** [OceaniaDx.cs](../src/Nonemm.Contests/Rules/OceaniaDx.cs), `PointsOn`, returns 1 for both bands. The local N1MM `COceania.ComputePoints` returns 2 and 3 respectively, also documented by the [WIA contest scoring table](https://www.wia.org.au/members/contests/oceania/). Both incorrect values were reproduced. The four supplied Oceania contacts do not exercise these bands, so their matching points do not cover this defect.
**Fixed 2026-09-10.** The whole table is written out as N1MM writes it — 20, 10, 5, 1, 2, 3 — and it ends where N1MM's ends, so a band that is not in the contest scores nothing rather than one point.
8. **P2 — New SARTG and BARTG contacts miss call-area multipliers.** [SartgRtty.cs](../src/Nonemm.Contests/Rules/SartgRtty.cs), line 35, and [BartgSprint.cs](../src/Nonemm.Contests/Rules/BartgSprint.cs), line 49, obtain call areas from `Qso.Section`. Neither entry definition includes that field, and `OperatingPosition.BuildQso` does not derive it from the call. A new SARTG `K1ABC` QSO returned only country `K`. N1MM's `CSARTGRTTY.MultSqlString2` fills an empty section from its call-area lookup for K, VE, JA and VK. Imported rows with cached sections can pass comparison while newly logged contacts fail. Add call-area derivation and test both fresh and imported contacts.
8. **P2 — New SARTG and BARTG contacts miss call-area multipliers.** [SartgRtty.cs](../src/Nonemm.Contests/Rules/SartgRtty.cs), line 45, and [BartgSprint.cs](../src/Nonemm.Contests/Rules/BartgSprint.cs), line 59, obtain call areas from `Qso.Section`. Neither entry definition includes that field, and `OperatingPosition.BuildQso` does not derive it from the call. A new SARTG `K1ABC` QSO returned only country `K`. N1MM's `CSARTGRTTY.MultSqlString2` fills an empty section from its call-area lookup for K, VE, JA and VK. Imported rows with cached sections can pass comparison while newly logged contacts fail. Add call-area derivation and test both fresh and imported contacts.
9. **P2 — IOTA cannot score an island entrant correctly.** [Iota.cs](../src/Nonemm.Contests/Rules/Iota.cs), line 40, depends only on the received reference. It gives 2 for a world station and 15 for any island. An island entrant should receive 5 for a world station or its own island group, and 15 for another group. The station's own reference needs to participate in scoring. This limitation is acknowledged in a comment, but that comment misses the island-to-world case. See the [2026 RSGB rules](https://www.rsgbcc.org/hf/rules/2026/riota.shtml).
9. **P2 — IOTA cannot score an island entrant correctly.** [Iota.cs](../src/Nonemm.Contests/Rules/Iota.cs), line 42, depends only on the received reference. It gives 2 for a world station and 15 for any island. An island entrant should receive 5 for a world station or its own island group, and 15 for another group. The station's own reference needs to participate in scoring. This limitation is acknowledged in a comment, but that comment misses the island-to-world case. See the [2026 RSGB rules](https://www.rsgbcc.org/hf/rules/2026/riota.shtml).
10. **P2 — IARU zones can be counted twice through formatting.** [IaruHf.cs](../src/Nonemm.Contests/Rules/IaruHf.cs), line 50, uses the exchange text as the multiplier value. Working zone `8`, then `08`, awarded two zone multipliers in the reproduction. N1MM's `CIaru.MultSqlString` formats numeric zones consistently. Parse and normalize zones before producing multiplier keys; validate zone versus HQ exchanges separately. This finding does not explain all historical IARU point differences above.
10. **P2 — IARU zones can be counted twice through formatting.** [IaruHf.cs](../src/Nonemm.Contests/Rules/IaruHf.cs), line 59, uses the exchange text as the multiplier value. Working zone `8`, then `08`, awarded two zone multipliers in the reproduction. N1MM's `CIaru.MultSqlString` formats numeric zones consistently. Parse and normalize zones before producing multiplier keys; validate zone versus HQ exchanges separately. This finding does not explain all historical IARU point differences above.
11. **P2 — CQ 160 maritime mobiles receive incorrect points and countries.** [CqOneSixty.cs](../src/Nonemm.Contests/Rules/CqOneSixty.cs), line 54, has no maritime exception. Through the shared country fallback, JA1XYZ/MM from Germany scored 10 and could claim Japan. The [CQ 160 rules](https://cq160.com/rules/index.htm) specify 5 points and no multiplier for a maritime mobile. Similar country fallback behavior exists in CQ WW; review it against each contest's rules rather than changing the common fallback indiscriminately. Some existing tests deliberately assert N1MM-like fallback behavior; the project objective explicitly says to follow published rules where N1MM is wrong.
11. **P2 — CQ 160 maritime mobiles receive incorrect points and countries.** [CqOneSixty.cs](../src/Nonemm.Contests/Rules/CqOneSixty.cs), line 62, has no maritime exception. Through the shared country fallback, JA1XYZ/MM from Germany scored 10 and could claim Japan. The [CQ 160 rules](https://cq160.com/rules/index.htm) specify 5 points and no multiplier for a maritime mobile. Similar country fallback behavior exists in CQ WW; review it against each contest's rules rather than changing the common fallback indiscriminately. Some existing tests deliberately assert N1MM-like fallback behavior; the project objective explicitly says to follow published rules where N1MM is wrong.
12. **P2 — Field Day is an unconditional approximation of one rules variant.** [FieldDayRegionOne.cs](../src/Nonemm.Contests/Rules/FieldDayRegionOne.cs), line 32, always uses portable=5, EU/AF fixed=2, other fixed=3. N1MM's `CFdReg1.ComputePoints` branches on the contest variant and the entrant's country; its generic fallback is 1. For the supplied Slovak FDREG1 instance, all 41 stored one-point QSOs were changed, raising the points to 181. Continent alone also cannot determine IARU Region 1. Identify the intended national/contest variant and its published rules before replacing these tables; there is no single safe universal table here.
12. **P2 — Field Day is an unconditional approximation of one rules variant.** [FieldDayRegionOne.cs](../src/Nonemm.Contests/Rules/FieldDayRegionOne.cs), line 40, always uses portable=5, EU/AF fixed=2, other fixed=3. N1MM's `CFdReg1.ComputePoints` branches on the contest variant and the entrant's country; its generic fallback is 1. For the supplied Slovak FDREG1 instance, all 41 stored one-point QSOs were changed, raising the points to 181. Continent alone also cannot determine IARU Region 1. Identify the intended national/contest variant and its published rules before replacing these tables; there is no single safe universal table here.
13. **P2 — Rescoring after edits does not persist all changed cached scores.** [ContestSession.cs](../src/Nonemm.Session/ContestSession.cs), lines 158 and 240, rebuilds the in-memory log after deletion or replacement but does not update every affected stored row. Deleting the first of two Japanese CQ WW contacts made the second contact a multiplier in memory while its stored flag remained false. Incoming network inserts have the same cache consistency concern. Explicit `Rescore` repairs these columns. N1MM itself documents manual rescoring after some edits, so this is principally a limitation of automatic interoperability: reopening the file in N1MM without a rescore can show stale totals. See [N1MM's log-window instructions](https://n1mm.hamdocs.com/manual-windows/log-window/).
13. **P2 — Rescoring after edits does not persist all changed cached scores.** [ContestSession.cs](../src/Nonemm.Session/ContestSession.cs), `Delete` and `DeleteFromNetwork`, rebuilds the in-memory log after deletion or replacement but does not update every affected stored row. Deleting the first of two Japanese CQ WW contacts made the second contact a multiplier in memory while its stored flag remained false. Incoming network inserts have the same cache consistency concern. Explicit `Rescore` repairs these columns. N1MM itself documents manual rescoring after some edits, so this is principally a limitation of automatic interoperability: reopening the file in N1MM without a rescore can show stale totals. See [N1MM's log-window instructions](https://n1mm.hamdocs.com/manual-windows/log-window/).
14. **P2 — The score window mixes unweighted and weighted multiplier counts.** [ScoreWindow.axaml.cs](../src/Nonemm.App/Windows/ScoreWindow.axaml.cs) sums Boolean flags for each band but uses `Tally.TotalMultipliers` for the total. A single WAE multiplier on 80M appears as 1 in the band row and contributes 4 to the total. QTC rows are also counted in the QSO column even though `Contest.IsContact` identifies them as traffic. Display raw multipliers, weights and QTC counts consistently. This does not by itself change WAE's correctly weighted total score.
**Not a fault; this is what N1MM does.** `ScoreRow.AddContact` adds the weight of a WAE multiplier, four on 80M and so on, to the band row and to the total alike, and `ScoreTally.AddMultiplier` has done the same since `d4d0375`. N1MM counts QTC rows as Qs too — `ValidQs` counts every row that reaches the score — and keeps them readable by splitting each WAE band into a row per kind under `Q/QTC`, which the score window here does as well. Taking the QTC rows out of the QSO column would leave N1MM's numbers behind.
**Not a fault; this is what N1MM does.** `ScoreTally.AddMultiplier` adds the weight of a WAE multiplier, four on 80M and so on, and the band row and the total are both a `ScoreTally`, so both have counted it that way since `d4d0375`. N1MM counts QTC rows as Qs too — `ValidQs` counts every row that reaches the score — and keeps them readable by splitting each WAE band into a row per kind under `Q/QTC`, which the score window here does as well. Taking the QTC rows out of the QSO column would leave N1MM's numbers behind.
**Coverage and remaining limits.** The 26 built-in families are CQ WW, CQ WPX, ARRL DX, IARU, Sweepstakes, WAE, ARRL RTTY Roundup, NAQP, OK/OM DX CW, YOTA, IOTA, EU DX, CQ 160, Mexico RTTY, REF, BARTG, ARRL 10M, Russian DX RTTY, RDAC, YO DX HF, Oceania, Region 1 Field Day, SARTG, All Asian and general logging. CW/SSB/RTTY variants share classes where the registry supplies a mode. This is a subset of [N1MM's supported contests](https://n1mm.hamdocs.com/manual-supported/contests-list/).
@@ -73,6 +75,6 @@ The following require further work before claiming full compatibility:
- There is no shared contest-band eligibility model. `ShowsWarcBands` controls presentation, not scoring. Several rules award points outside their contest bands; WAE has an explicit band check. Separate band validity from N1MM's permissive frequency-to-band mapping.
- The core score types use `int`, including products. Very large scores or UDC bonuses can overflow. Establish supported bounds and use a wider score type if needed.
- The historical YOTA, EU DX, CQ WW and IARU differences need individual row analysis with the original station setup and country/history files. Do not change rules merely to force agreement with potentially stale caches.
- Rig, keying, digital, cluster and network transport behavior was not certified by this scoring review. Existing limitations are documented in [unfinished.md](unfinished.md), which also contains stale or contradictory status statements.
- Rig, keying, digital, cluster and network transport behavior was not certified by this scoring review. Existing limitations are documented in [unfinished.md](unfinished.md).
Fix entry completion and the three serial exporters first, then excluded-contact scoring and the contest-specific P1 findings. Add targeted regression tests from these reproductions, including fresh entry through `OperatingPosition`, followed by database and Cabrillo checks. For each contest, cover both entrant sides and every scoring band before describing it as compatible.
Of what is left, finding 5 comes first: BARTG HF and Sprint are two contests under one name, so a Sprint log is scored by the wrong rules and a log started here is written with the other contest's name. Then findings 8, 10 and 11, which are wrong scores in ordinary contacts, then 6, 9 and 12, which need the published multiplier lists and rule variants read out first, then 13. Add targeted regression tests from these reproductions, including fresh entry through `OperatingPosition`, followed by database and Cabrillo checks. For each contest, cover both entrant sides and every scoring band before describing it as compatible.