The roundwork package was outsourced from scrutiny, a much larger and less focused package. (See this Github issue for the rationale.)
roundwork only contains the rounding layer:
round_up(),
round_ceiling(), round_ties_away(), and so
on);reround(), the interface that names each procedure by a
string;unround() and bound_numerators(), which
run the same procedures backwards to recover the range of an unknown
original number;sum_range(), which finds the whole-number sums behind a
rounded mean;reround_to_fraction() and
rounding_bias();resolve_ties_rounding(), for functions that branch on
rounding themselves.The error detection techniques that build on this layer — GRIM, GRIMMER, DEBIT — live in scrutiny. From version 1.0.0 on, scrutiny imports its rounding from roundwork and no longer exports any rounding functions of its own.
Before its 1.0.0 version, scrutiny had its own copies of the rounding
functions, some of them under the same names. Attaching both packages —
roundwork and an older version of scrutiny — can create ambiguity. These
copies are older, and some of them behave differently: for example,
round_down_from() reads threshold differently
there.
I strongly recommend using scrutiny 1.0.0 or later. However, just in case you use roundwork together with scrutiny 0.6.1 or earlier, use the conflicted package to clarify which package you mean when you call certain functions:
library(conflicted)
library(scrutiny)
library(roundwork)
conflict_prefer_matching("round", "roundwork", quiet = TRUE)
conflict_prefer("anti_trunc", "roundwork", quiet = TRUE)You can then run round_up without parentheses and check
the namespace signature at the bottom. If it says
namespace:roundwork, everything is fine. If not, please open an
issue.
Package developers can simply use package::function()
syntax, as usual, or call usethis::use_import_from(). With
scrutiny 1.0.0 or later, there is no conflict to resolve.