The remaining S3 methods will be un-exported in the next release:
[<-.integer64, abs.integer64,
all.integer64, any.integer64,
as.character.integer64,
as.data.frame.integer64, as.double.integer64,
as.integer.integer64, as.integer64.character,
as.integer64.double, as.integer64.integer,
as.integer64.logical, c.integer64,
format.integer64, is.na.integer64,
log.integer64, max.integer64,
min.integer64, print.integer64,
rank.integer64, rep.integer64,
seq.integer64, str.integer64,
sum.integer64, unique.integer64
All of these have observed downstream calls directly. If the call is in a CRAN/Bioconductor package, I’ll be reaching out to help migrate onto the generic. This will probably take at least a year, so don’t expect this to induce a CRAN release per se until 2027 (although you should certainly aim to slip this in to your next release in the meantime).
When integer64 and character are combined, the result will be
character. This prevents loss of information, e.g. in
c(as.integer64(1L), "a") and
c(as.integer64(1L), "999999999999999999999999"). Use the
option bit64.promoteInteger64ToCharacter set to
TRUE to try this in advance for c.integer64,
cbind.integer64, rbind.integer64,
[.integer64<-, [[.integer64<-,
union, intersect, setdiff, and
is.element.
keep.names will be removed from
as.integer64() methods, e.g. double. Allowing
keep.names is inconsistent with other vector coercions like
as.integer(), as.double(),
as.character(), … which strip names. Therefore, starting
from the next release, it will be a warning to use this argument; users
should just add code to retain the names if so desired.
{bit64} no longer Depends on {bit}; instead it
Imports it. Here I copy the advice from 4.6.0-1 about how
to adapt to this as a user depending on {bit64} if it affects you:
Users relying on Depends in scripts can (1) write
library(bit) to attach {bit} explicitly or (2)
namespace-qualify all {bit} calls with bit::.
Package authors relying on Depends can (1) add
import(bit) to make the full {bit} namespace available or
(2) namespace-qualify all {bit} calls with bit::; adding
{bit} to Imports: or Suggests: will also be
necessary.
The following S3 methods were directly removed from the NAMESPACE:
-.integer64, :.default,
:.integer64, !.integer64,
!=.integer64, [.integer64,
[[.integer64, [[<-.integer64,
*.integer64, /.integer64,
&.integer64, %/%.integer64,
%%.integer64, %in%.default,
%in%.integer64, ^.integer64,
+.integer64, <.integer64,
<=.integer64, ==.integer64,
>.integer64, >=.integer64,
|.integer64, all.equal.integer64,
as.bitstring.integer64,
as.integer64.bitstring, as.integer64.factor,
as.integer64.integer64, as.integer64.NULL,
as.list.integer64, as.logical.integer64,
cbind.integer64, ceiling.integer64,
cummax.integer64, cummin.integer64,
cumprod.integer64, cumsum.integer64,
diff.integer64, duplicated.integer64,
floor.integer64, hashdup.cache_integer64,
hashfin.cache_integer64, hashfun.integer64,
hashmap.integer64, hashmaptab.integer64,
hashmapuni.integer64, hashmapupo.integer64,
hashpos.cache_integer64,
hashrev.cache_integer64,
hashrin.cache_integer64,
hashtab.cache_integer64,
hashuni.cache_integer64,
hashupo.cache_integer64, is.double.default,
is.double.integer64, is.finite.integer64,
is.infinite.integer64, is.nan.integer64,
is.sorted.integer64, is.vector.integer64,
keypos.integer64, length<-.integer64,
log10.integer64, log2.integer64,
match.default, match.integer64,
mean.integer64, median.integer64,
mergeorder.integer64, mergesort.integer64,
mergesortorder.integer64, na.count.integer64,
nties.integer64, nunique.integer64,
nvalid.integer64, order.default,
order.integer64, orderdup.integer64,
orderfin.integer64, orderkey.integer64,
ordernut.integer64, orderpos.integer64,
orderqtl.integer64, orderrnk.integer64,
ordertab.integer64, ordertie.integer64,
orderuni.integer64, orderupo.integer64,
prank.integer64, print.bitstring,
prod.integer64, qtile.integer64,
quantile.integer64, quickorder.integer64,
quicksort.integer64, quicksortorder.integer64,
radixorder.integer64, radixsort.integer64,
radixsortorder.integer64, ramorder.integer64,
ramsort.integer64, ramsortorder.integer64,
range.integer64, rank.default,
rbind.integer64, round.integer64,
scale.integer64, shellorder.integer64,
shellsort.integer64, shellsortorder.integer64,
sign.integer64, signif.integer64,
sort.integer64, sortfin.integer64,
sortnut.integer64, sortorderdup.integer64,
sortorderkey.integer64,
sortorderpos.integer64,
sortorderrnk.integer64,
sortordertab.integer64,
sortordertie.integer64,
sortorderuni.integer64,
sortorderupo.integer64, sortqtl.integer64,
sorttab.integer64, sortuni.integer64,
sqrt.integer64, summary.integer64,
tiepos.integer64, trunc.integer64,
unipos.integer64
Previously, it was noted that this release would feature a warning to nudge towards correcting direct calls, but that has proven infeasible – R’s evaluation rules are simply too complex to warrant an expensive haystack search for the generic in the call stack each time a method is invoked. In some cases it is also not possible, period.
Because there was no recorded direct usage for any of these, I am opting to just rip the band-aid off and un-export them in this release as opposed to waiting a full cycle more to do so.
as.integer64.integer64 returns a plain
integer64 vector stripped of any attributes. This is
consistent with R-like behavior,
e.g. as.integer.integer.
%/% matches base R/Knuth behavior of taking the
floor() of a result, where previously truncation was
towards zero. For example,
as.integer64(-10L) %/% as.integer64(7L) now gives
-2L, not -1L. This is consistent with
-10L %/% 7L in base R. Consequently, %% is
also affected, e.g. as.integer64(-10L) %% as.integer64(7L)
now gives 4L, not -3L, consistent with
-10L %% 7L in base R.
anyNA gets an integer64 method. Thanks
@hcirellu.table now gets a generic function and
table.integer64 is extended by base::table
parameters exclude and useNA (#59). Thanks
@hcirellu. Note that
as of now, for multiple inputs like table(x, y, z), the
efficient table.integer64 implementation is only invoked if
all of x, y, and z can
be losslessly coerced to integer64. If, say, y
is a character vector, the default method will be applied, leading to
x being coerced to character (and then
factor), which can result in unexpected ordering of the
results when negative numbers are included. To get around this, do
coercion yourself first (either coerce all inputs to
integer64 to get the fast implementation, or coerce the
integer64 input(s) to factor with the desired
ordering).seq() method for integer64 has been
overhauled to better match features from the default method.
seq(as.integer64(1L), 11L, length.out=6L) calculated
by= incorrectly to give 1:6 instead of
c(1L, 3L, ..., 9L, 11L).length.out= was also sometimes ignored, for example
seq(to=as.integer64(5L), length.out=0L) will now always
just give integer64().seq(a, a, by=by) is no longer an error.from=1
and to=1 if needed in order to support usage like
seq(as.integer64(10L), by=-1L) and
seq(by=as.integer64(3L), length.out=8L).seq(a, a, length.out=n) will give
rep(a, n), not
seq(a, by=1, length.out=n).as.Date, as.POSIXct,
as.POSIXlt, as.complex, and
as.raw get an integer64 method.as.integer64 gets Date,
POSIXct, POSIXlt, complex,
raw, and difftime methods.as.integer64.character:
as.integer64("0x7FFFFFFFFFFFFFFF"). Thanks
@hcirellu for a PR
which completes work begun by @marcpaterno.as.integer(); #232).sortcache, sortordercache and
ordercache get a new argument na.last.matrix, array, %*% and
as.matrix get an integer64 method (#45).
Thanks @hcirellu.factor, as.factor, ordered,
and as.ordered support integer64 input
correctly, i.e. the levels are sorted according to
integer64 values. Thanks @hcirellu.[<- or [[<- with a complex or POSIXct
leads to an R consistent coercion of the integer64 object to a complex
or POSIXct object and not just an error. Thanks @hcirellu.union, setdiff, intersect,
setequal and is.element get an overload to
work correctly with integer64 (#182).+,
&, ==) now support dispatch for both
arguments so that e.g. difftime * integer64 works
consistent with R (#179). Thanks @hcirellu. Note that this relies on
chooseOpsMethod() and thus R 4.3.0.c.integer64, cbind.integer64 and
rbind.integer64 now support combining with lists and
recursion as base::c, base::cbind and
base::rbind do (#252). In addition, by setting the option
bit64.promoteInteger64ToCharacter=TRUE the methods return
character if integer64 and character are combined. Thanks @hcirellu.min.integer64, max.integer64 and
range.integer64 now support na.rm=TRUE
correctly when combining across multiple inputs like
min(x, NA_integer64_, na.rm=TRUE) (#142).as.integer64.integer64 is consistent with
as.integer.integer in terms of returning a plain integer64
vector (i.e., stripped of attributes; #188). Thanks @hcirellu.log(integer64(), base=integer64(1)) no longer warns,
consistent with log(integer(), base=integer()) (#93).sortfin(integer64(), 1:10) no longer segfaults
(#164).orderfin(as.integer64(10:1), 1:3, 8:11) enforces that
table be sorted by order instead of
segfaulting (#166).ordertab() no longer segfaults when
nunique is smaller than the actual number of unique values
(#168).as.integer64.character now returns NA for
out of range values, with warning,
e.g. as.integer64("22222222222222222222") (#175). Thanks
@hcirellu.quicksort() and others no longer segfault on trivial
cases (e.g. sorting 0 or 1 item, #220).as.integer64(2^63) returns NA_integer64_
more consistently (e.g. on ARM), consistent with
as.integer(2^31) (#19). Thanks @dipterix.[.integer64 now runs faster and correctly regarding
NA and arrays (#176). Thanks @hcirellu.integer64() %in% 1L no longer warns (#265). Thanks
@hcirellu.match.integer64(..., method="orderpos") and
duplicated.integer64(..., method="orderdup") no longer fail
with “object ‘s’ not found” (#58).median(NA_integer64_, na.rm=FALSE) and
median(integer64()) now return NA_integer64_,
aligning its behavior with median(NA_integer_), #185.
Previously the former threw an error while the latter gave an incorrect
result. Thanks @ben-schwen for the report and the
PR..onAttach() hook (#106). Thanks @hadley for the request.as.bitstring() only makes a simple adjustment,
namely, for as.bitstring() to add two new attributes
(nbits and type). Everything else should
continue to work as before.I plan to un-export most if not all S3 methods in future versions. In
this release, there will be no change in behavior besides this notice in
the NEWS. Going forward, I see two types of S3 exports: (1) exports that
have no discoverable direct usage (that is, a global GitHub search,
which includes the CRAN mirror, turned up no R code calling
them directly, except perhaps in ::: form, which would be
unaffected by un-export); and (2) exports that are observed to
be called directly by some number of downstreams. With the former, I am
more comfortable un-exporting more aggressively; with the latter, I will
take a more gradual approach.
Here are the S3 methods that are currently exported, for which I found no record of them being called directly:
-.integer64, :.default,
:.integer64, !.integer64,
!=.integer64, [.integer64,
[[.integer64, [[<-.integer64,
*.integer64, /.integer64,
&.integer64, %/%.integer64,
%%.integer64, %in%.default,
%in%.integer64, ^.integer64,
+.integer64, <.integer64,
<=.integer64, ==.integer64,
>.integer64, >=.integer64,
|.integer64, all.equal.integer64,
as.bitstring.integer64, as.integer64.factor,
as.integer64.integer64, as.integer64.NULL,
as.list.integer64, as.logical.integer64,
cbind.integer64, ceiling.integer64,
cummax.integer64, cummin.integer64,
cumprod.integer64, cumsum.integer64,
diff.integer64, duplicated.integer64,
floor.integer64, hashdup.cache_integer64,
hashfin.cache_integer64, hashfun.integer64,
hashmap.integer64, hashmaptab.integer64,
hashmapuni.integer64, hashmapupo.integer64,
hashpos.cache_integer64,
hashrev.cache_integer64,
hashrin.cache_integer64,
hashtab.cache_integer64,
hashuni.cache_integer64,
hashupo.cache_integer64, is.double.default,
is.double.integer64, is.finite.integer64,
is.infinite.integer64, is.nan.integer64,
is.sorted.integer64, is.vector.integer64,
keypos.integer64, length<-.integer64,
log10.integer64, log2.integer64,
match.default, match.integer64,
mean.integer64, median.integer64,
mergeorder.integer64, mergesort.integer64,
mergesortorder.integer64, na.count.integer64,
nties.integer64, nunique.integer64,
nvalid.integer64, order.default,
order.integer64, orderdup.integer64,
orderfin.integer64, orderkey.integer64,
ordernut.integer64, orderpos.integer64,
orderqtl.integer64, orderrnk.integer64,
ordertab.integer64, ordertie.integer64,
orderuni.integer64, orderupo.integer64,
prank.integer64, print.bitstring,
prod.integer64, qtile.integer64,
quantile.integer64, quickorder.integer64,
quicksort.integer64, quicksortorder.integer64,
radixorder.integer64, radixsort.integer64,
radixsortorder.integer64, ramorder.integer64,
ramsort.integer64, ramsortorder.integer64,
range.integer64, rank.default,
rbind.integer64, round.integer64,
scale.integer64, shellorder.integer64,
shellsort.integer64, shellsortorder.integer64,
sign.integer64, signif.integer64,
sort.integer64, sortfin.integer64,
sortnut.integer64, sortorderdup.integer64,
sortorderkey.integer64,
sortorderpos.integer64,
sortorderrnk.integer64,
sortordertab.integer64,
sortordertie.integer64,
sortorderuni.integer64,
sortorderupo.integer64, sortql.integer64,
sorttab.integer64, sortuni.integer64,
sqrt.integer64, summary.integer64,
table.integer64, tiepos.integer64,
trunc.integer64, unipos.integer64
Here are the S3 methods that are currently exported for which I do find record of them being called directly:
abs.integer64, as.character.integer64,
as.data.frame.integer64, as.double.integer64,
as.integer.integer64, as.integer64.bitstring,
as.integer64.character, as.integer64.double,
as.integer64.integer, as.integer64.logical,
c.integer64, format.integer64,
identical.integer64, is.na.integer64,
lim.integer64, max.integer64,
min.integer64, print.integer64,
rank.integer64, seq.integer64,
str.integer64, sum.integer64,
unique.integer64
In the next release (provisionally, 4.7.0), I will add a
warning() to any S3 method in the former classification,
while nothing will change for the latter classification. I may reach out
to authors observed to call the methods directly.
In the subsequent release (provisionally, 4.8.0), I will un-export
any S3 method in the former classification, and add a
warning() to any S3 method in the latter
classification.
In the sub-subsequent release (provisionally, 4.9.0), I will un-export any S3 method in the latter classification.
Please reach out (e.g., the GitHub log for #76) if you have any concerns about this plan.
Depends:. IMO this form of
dependency should be deprecated by R now that Imports: is
widely available and well-supported for many years.In the next release (provisionally, 4.7.0), I will move bit to
Imports. The practical implication is that currently,
library(bit64) will make {bit} objects like
is.bit() available for use without namespace-qualification.
This practice makes code harder to read and maintain.
Users relying on this in scripts can (1) write
library(bit) to attach {bit} explicitly or (2)
namespace-qualify all {bit} calls with bit::.
Package authors relying on this can (1) add import(bit)
to make the full {bit} namespace available or (2) namespace-qualify all
{bit} calls with bit::; adding {bit} to
Imports: or Suggests: will also be
necessary.
I will reach out to CRAN authors with any required changes. Depending on the impact size, I might make this transition more gradual (e.g. starting by re-exporting some or all {bit} functions from {bit64}, with warning, before un-exporting them in a subsequent release).
rowSums() and
colSums(). Importantly they handle NA values
correctly, #38. Thanks @vlulla for the request. Note that these are
implemented as wrappers to apply() calls, so they may not
be as efficient. PRs welcome for implementing the efficient
equivalents.Note that by necessity, this grows the set of base exports
overwritten to include rowSums() and
colSums(), which are exported as S3 generics dispatching to
base::rowSums() and base::colSums() by
default.
Partially powering this is a new aperm() method for
integer64 which allows apply() to work as intended. Using
apply() directly may still strip the integer64 class; that
may be supported later (see #87).
is.na() is supported for long vector input (more
than 2^31 elements), #30. Thanks @ilia-kats for the request. Long vector
support will be added on an as-needed basis as I don’t have a great
machine for testing these features – PRs welcome!
all.equal.integer64() gets the same fix for vector
scale= to work as intended that
all.equal.numeric() got in R 4.1.3, #23.
Made edits to match() to handle
is.integer64(table) better for older versions of R,
including a new mtfrm() method for integer64 objects in
R>=4.2.0, #85 and #111.
I don’t have any major plans for new features, and mostly hope to keep the package running and up to date. Contributors most welcome! I am also trying to freshen up the code base to make contribution easier.
Required package {bit} already requires R 3.4.0, so the old 3.0.1 requirement was effectively impossible anyway.
Imports:, not Depends:, dependencies.
Depends: is an out-dated mode of dependency in R. This will
only affect the small audience of users that run R with
R_DEFAULT_PACKAGES=NULL (or some other subset excluding
some of these three), and who are relying (perhaps implicitly)
on {bit64} being responsible for attaching those packages.It is my intention to move {bit} from Depends: to
Imports: as well, but this migration will be done more
gingerly – it is more conceivable that this will constitute a breaking
change for some use cases, therefore it will be done in phases. Nothing
is done in this release, but here is your earliest warning that from the
next release, it will be a warning to rely on {bit64} to attach {bit}
functions for you.
Package documentation is now managed with {roxygen2}, #61. I tried to retain everything in the original documentation, but the diff required to do so was quite unmanageable (5,000+ lines), so please alert me if anything looks amiss. Most importantly, I ensured the NAMESPACE remains unchanged.
The signature of identical.integer64() loses
extptr.as.ref=, which is unavailable for R<4.2.0, but
gains ... to allow this argument in newer versions, #37.
This retains the transparency of having all arguments named in the
signature (and thus in ?identical.integer64 as well as
available for tab-completion) while also retaining the old R version
dependency R 3.3.0.