Fix decimal percentages and scientific probability literals in binomial questions
The statistics organs currently answer P(X=1)=0.5 for two trials with p=0.5%. The probability is 0.005, so the correct answer is 0.00995. The decimal alternative in the probability regex matches before the % alternative and leaves the suffix unread. Scientific notation has the same prefix defect: p=0.5e-2 is read as 0.5.
Consume the complete signed decimal/scientific scalar and its optional percentage suffix, then convert the percentage. Reject malformed or unsupported scalar continuations instead of accepting a numeric prefix. Share this grammar between v1 and v2 within each self-contained specialist directory, and apply the existing binomial-domain check to v1 as well. All five deployed source copies are covered.
Before float conversion, a shared bounded Fraction decoder validates the exact probability domain. It caps the scalar at 4096 characters and the exponent magnitude at 10000, then refuses nonzero probabilities that round to float zero and probabilities below one that round to float one. Thus 1e-10000, a long decimal just above one, and a long decimal just below one cannot silently become endpoint probabilities. Nonzero representable subnormal inputs and actual zero/one endpoints remain accepted. This does not replace the existing floating-point mass formula or claim numerical accuracy for all extreme tails.
The portable unittest suite independently enumerates Bernoulli sequences with exact rational masses. It checks all successes counts for 0–5 trials, decimal-percent/exponent equivalence, endpoint probabilities, all v2 probability-role spellings, out-of-domain probabilities and malformed continuations. The exact pinned source fails 688 assertions/subtests; the patch passes all five test methods. These are untrusted Python regressions, not formal proofs.
All 860 shipped panel items were run through their own shipped scorers before and after: unchanged replies throughout, zero wrong answers and zero false yes. Scorer-correct totals including correct declines are statistics dev 142/142 and heldout 128/142; statistics-v2 144/144 and 130/144; statistics-v3 144/144 on both splits. Existing v1 binomial-phrasing and v2 data-set-phrasing misses remain.
Reference: NIST binomial mass function. This repair binds the stated probability to that existing formula; it adds no distribution or inference model.
Base: c473d28914e480425adb29b4f7f42485b8cfb4e3 (current main checked 29 October 2026). Run python -B -m unittest discover -s tests/statistics -v.
Thank you. #8 and #9 shipped in 10.3.1, slim and full, credited to you by name in CHANGELOG_1031.md, with your 16 tests under tests/. They pass on both trees and fail against the previous sources, and all 860 panel items give the same reply before and after. The 0.5% prefix match was a real wrong answer, and testing your fix found the same defect in the math organ, which is fixed too.
One question on #9. k > n is now withheld ("k ≤ n" in the refusal). Before, it computed C(n, k) = 0 and answered P = 0, which is correct: "exactly 5 successes in 3 trials" has probability 0 for any p. Withholding isn't wrong, but it loses a right answer. Was the refusal intended, or should k > n answer 0? If it was a side effect, a small follow-up would be welcome. The changelog lists it as open.
Chat doesn't route binomial questions to the statistics specialist yet, so the fix reaches users through operations / invoke and the specialist directly. That part is on us.
#10 is a good find. It changes reader_v7.py, which our release test hashes to carry the held-out results, so it gets its own measurement and ships with that, credited to you.
Agreed—more successes than trials is a valid event with probability zero. The follow-up is now PR #11, against 10.3.1. It validates the count/probability domains before returning zero, including n=0,p=1, and fixes count-token truncation (-3, 3.5, 3e2) in the same binomial readers. Ordinary comma/parenthesis delimiters are preserved.
Both separately pinned slim/full trees pass eight new methods plus the five existing probability-binding methods; all 860 shipped statistics-panel replies are unchanged on each tree, with zero wrong/false-yes through their scorers. The tests use independent exact Bernoulli enumeration for small masses. This is a specialist repair, not a claim that the current whole-head route now admits those constant-zero answers; the PR describes that remaining distinction.
A correction to my reply above. I wrote that #9's fix reaches users through operations / invoke and the specialist directly. That was wrong, and you were right on #11: on 10.3.1 invoke refuses the statistics specialists (specialist.statistics and -v2 are unavailable, -v3 returns not_directly_invocable), and chat declines the question. So the fix is in the specialist code and its tests, but no user path reaches it yet. The same sentence is in CHANGELOG_1031.md and the v40 pre-registration; the next release's changelog will correct it, and routing binomial questions to the specialist is the real fix.
Thank you for #11; it's being reviewed for that release, along with the measurement for #10.