[davidchall]

Why

Particle Data Group rounding treats uncertainties whose leading three digits fall in the 950-999 range as a special case: they round up to 1000 and keep two significant digits. The previous logic treated those values like the 355-949 case, which produced a one-digit uncertainty instead of the expected two-digit result.

What changed

• corrected the PDG digit selection so 950-999 uncertainties keep two significant digits
• added the 1000-up rounding step before formatting those values
• added a regression test covering the reported 0.827 +/- 0.962 case

Fixes #65

[Enchufa2]

Thanks @davidchall for spinning this! I reviewed it with our French Friend and found some issues, they were simple enough, so I committed them directly:

• Fix the 950 boundary: values that land exactly on the 950 boundary (e.g. 0.95, or 0.9495 once it rounds to three digits) were being rounded down by round(), giving 1.00 ± 0.90. Uncertainties in the 950–999 range are now set straight to the next power of ten, so they print as 1.0 ± 1.0.
• Single rounding step: the uncertainty is now rounded once, at the top of format.errors(), instead of being rounded and then partly overwritten.
• Shared helper: the three-highest-order-digit extraction now lives in one helper, pdg_hod(). digits_pdg() uses its result, and pdg_round_to_1000() is gone.
• Less repeated work: the uncertainties are extracted once and the digit extraction runs once per call.
• Tests: added cases for the 950 boundary (0.95, 0.9495), larger and smaller uncertainties (96.2, 9.62e-6), and the parenthesis, plus-minus and scientific notations.

@davidchall @alusiani Could you please try this?

[alusiani]

...

@davidchall @alusiani Could you please try this?

I tested the patched errors package, I found it 100% compliant with PDG prescriptions. You can go ahead, this is an improvement of the released code.