Skip to content

rounding: infer display precision from context #212

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
elong0527 merged 1 commit into from
Sep 8, 2026
+19 −18
Merged

rounding: infer display precision from context #212

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions rounding/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ with trailing zeros.

## What it does

Given a pinned repository and an approved display-precision specification,
Given a pinned repository and a display-precision specification when available,
the skill inventories every operation that can change a displayed number or a
number that decides which rows appear. It scans installed R code plus executable
reporting logic in scripts, READMEs, and vignettes (`.R`, `.Rmd`, `.qmd`,
Expand Down Expand Up @@ -37,7 +37,9 @@ first and audit the working tree read-only.
## Inputs

- Pinned source tree and the report entry points
- Display-precision spec per reported statistic
- Display-precision spec per reported statistic when available; otherwise the
audit infers digits from reporting context and assumes trailing zeros are
required, recording the rationale
- Tie policy and version, and the comparison helper the rule owner selected
- The rule owner's name
- Optional allowlist of sites already classified
Expand Down
28 changes: 13 additions & 15 deletions rounding/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ description: >
license: MIT
metadata:
author: Pharma Skills community
version: "0.8"
version: "0.9"
rules-version: "BR-001/002/003 v1.0"
---

Expand Down Expand Up @@ -75,8 +75,12 @@ Collect these before scanning. A rule the request is silent on is

- **Target**: a local folder or a repo link pinned to a commit, read-only. Pin
it: an unpinned reference silently stops reproducing when the source moves.
- **Precision spec**: required digits and trailing-zero expectation per
reported statistic. A statistic with no entry is `NOT ASSESSABLE`.
- **Precision spec**: preferred digits and trailing-zero expectation per
reported statistic. If absent, infer digits from the reporting context
(literal `digits`, function defaults, table labels, and paired examples) and
default trailing-zero expectation to `true`. Record the inference and its
source; use `NOT ASSESSABLE` only when the context supplies no defensible
precision.
- **Tie policy and its version**, plus the comparison helper the rule owner
selected and that package's version.
- **Entry paths**: exported report functions, scripts, and executable chunks in
Expand Down Expand Up @@ -246,18 +250,12 @@ usually settle the entry points; a call with a literal `digits` argument
carries its own precision. A gap you can close by reading is not a blocker, and
listing it as one is a false blocker that costs the reader a real audit.

If a gap survives that, audit everything it does not touch and mark only the
affected cells `NOT ASSESSABLE`, naming the specific missing item. A statistic
with no precision entry has an unassessable Display verdict. That says nothing
about its tie method, nothing about its rounding stage, and nothing whatever
about the other statistics -- a site whose precision is written into the source
as `round(x, 0)` is fully assessable on the tie rule no matter what the spec
omits.

Do not let the source stand in for the spec, though. A roxygen comment saying
"2 decimals" is the code describing itself, so grading the code against it is
circular. Use such a comment to choose probe precisions, never to award a
Display `PASS`.
If a gap survives that, infer the narrowest defensible display expectation from
the reporting context: literal `digits`, function defaults, table labels, and
paired examples. Default trailing zeros to required. Record the inference with
its exact source and assess the Display cell against it. Use `NOT ASSESSABLE`
only if no such context exists. That says nothing about its tie method, nothing
about its rounding stage, and nothing whatever about the other statistics.

A review that reports nothing because one input was missing is worse than one
that proves what it can and states exactly what it could not: the reader learns
Expand Down
3 changes: 2 additions & 1 deletion rounding/assets/report-template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@
Target: [<repo link pinned to commit>](<url>) or folder path: <path>
Environment: <R.version.string>
Policy: <tie policy and version; e.g. half away from zero 2.5->3, rule owner: Name>
Display inference: <approved spec, or contextual digits source; trailing zeros default to required>
Status: **Draft for review.** No source was changed and nothing was posted.
Verdict: **<PASS / FAIL / NOT ASSESSABLE>** (FAIL if any row fails, NOT ASSESSABLE if none fails and at least one is uncheckable, else PASS).

Expand Down Expand Up @@ -44,7 +45,7 @@ Attribute `formatC`/`sprintf` divergence to two causes (tie mode + binary repres

## Appendix C. Limitations

- Missing inputs: <which rule/row is NOT ASSESSABLE and what is missing, e.g. `report_ci()` has no entry in `precision-spec.yml`>
- Display inference: <approved spec or contextual source for digits; `NOT ASSESSABLE` only when neither exists>
- Blind spots: dynamic dispatch (`do.call`, `get`, `match.fun`), S3/S4 methods, dependency internals
- Untraced paths: <any entry path not fully traced>

Expand Down