$ in the currency-prefix matcher has no left boundary, so any unlisted currency code ending in $ is read as US dollars.
Baseline: this needs #30, which introduces the prefix matcher. On main today all four cases below are unscoreable, because the currency never reaches reconcile at all — that is the #23 bug, not a safeguard.
python3 -c "
import score
for t in ['About A\$50 per tCO2e.', 'About C\$80 per tCO2e.',
'About R\$100 per tCO2e.', 'About S\$25 per tCO2e.']:
print(t, '->', score.best_value(t, 'USD/tCO2e'))
"About A$50 per tCO2e. -> (50.0, '$ per tCO2e.', None)
About C$80 per tCO2e. -> (80.0, '$ per tCO2e.', None)
About R$100 per tCO2e. -> (100.0, '$ per tCO2e.', None)
About S$25 per tCO2e. -> (25.0, '$ per tCO2e.', None)
NT$ is handled because it was enumerated after it turned up in the answers. The others are not, so R$100 — about USD 18 — scores as 100 against a US-dollar truth. That is a ~5x error presented as a confident answer, which is worse than the unscoreable it would have been before the prefix matcher existed.
No live hits today
The corpus does contain A$ and S$ (reporting.aasb_s2.group1.applicability, reporting.aasb_s2.group3.applicability, reporting.sgx_acra.listed_non_sti_ge_1bn), but every one of those questions has a date truth, so the answers are unscoreable for an unrelated reason. Nothing in results/ is currently mis-scored by this. It is latent, not live.
Why it is worth fixing anyway
Enumerating known codes means the failure mode is silent and the default is wrong: a currency nobody listed becomes USD rather than becoming unscoreable. The holdout split is pre-registered and has never been scored, so the first time this bites may well be on the numbers that matter most.
Suggested fix
Require that the $ alternative is not preceded by a letter, and treat a <letters>$ form that is not a known code as an unknown currency — which, after #31, means reconcile refuses it rather than assuming USD.
Worth a test per code, in the style of verify/test_currency_mismatch.py.
Found while reviewing #30.
$in the currency-prefix matcher has no left boundary, so any unlisted currency code ending in$is read as US dollars.Baseline: this needs #30, which introduces the prefix matcher. On
maintoday all four cases below are unscoreable, because the currency never reachesreconcileat all — that is the #23 bug, not a safeguard.NT$is handled because it was enumerated after it turned up in the answers. The others are not, soR$100— about USD 18 — scores as 100 against a US-dollar truth. That is a ~5x error presented as a confident answer, which is worse than the unscoreable it would have been before the prefix matcher existed.No live hits today
The corpus does contain
A$andS$(reporting.aasb_s2.group1.applicability,reporting.aasb_s2.group3.applicability,reporting.sgx_acra.listed_non_sti_ge_1bn), but every one of those questions has a date truth, so the answers are unscoreable for an unrelated reason. Nothing inresults/is currently mis-scored by this. It is latent, not live.Why it is worth fixing anyway
Enumerating known codes means the failure mode is silent and the default is wrong: a currency nobody listed becomes USD rather than becoming unscoreable. The holdout split is pre-registered and has never been scored, so the first time this bites may well be on the numbers that matter most.
Suggested fix
Require that the
$alternative is not preceded by a letter, and treat a<letters>$form that is not a known code as an unknown currency — which, after #31, meansreconcilerefuses it rather than assuming USD.Worth a test per code, in the style of
verify/test_currency_mismatch.py.Found while reviewing #30.