Log message:
(devel/R-bit64) Updated 4.6.0.1 to 4.8.0
# bit64 4.8.2 (2025-05-19)
--------------------------
## BUG FIXES
1. Fix some potential segfaults from shellsort algorithms (#315). The
culprit code has been faulty for many years, but only newly caught by
CRAN's rigorous environment with extensive new test coverage.
1. `==` and other comparators (`!=`, `>`, `<`, `>=`, `<=`) correctly
match integer behavior when comparing integer64 and character/factor,
e.g. `as.integer64(1) == "1"` (#323).
# bit64 4.8.0 (2025-04-19)
--------------------------
## NOTICE OF PLANNED BREAKING CHANGES
1. 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).
1. 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`.
1. `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.
## BREAKING CHANGES
1. {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.
1. 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.
1. `as.integer64.integer64` returns a plain `integer64` vector
stripped of any attributes. This is consistent with R-like behavior,
e.g. `as.integer.integer`.
1. `%/%` 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.
## NEW FEATURES
1. `anyNA` gets an `integer64` method. Thanks @hcirellu.
1. `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).
1. The `seq()` method for `integer64` has been overhauled to better
match features from the default method. - The motivation is #47,
where `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. - We
match the default method behavior of assuming `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)`.
1. Coercion to/from integer64 is expanded greatly (includes
#199). Thanks @hcirellu.
- `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.
1. `as.integer64.character`:
- Supports hexadecimal (base 16) input when prefixed with "0x" or
"-0x", e.g. `as.integer64("0x7FFFFFFFFFFFFFFF")`. Thanks
@hcirellu for a PR which completes work begun by @marcpaterno.
- Ignores leading/trailing whitespace (as does `as.integer()`;
#232).
1. `sortcache`, `sortordercache` and `ordercache` get a new argument
`na.last`.
1. `matrix`, `array`, `%*%` and `as.matrix` get an `integer64` method
(#45). Thanks @hcirellu.
1. `factor`, `as.factor`, `ordered`, and `as.ordered` support
`integer64` input correctly, i.e. the levels are sorted according to
`integer64` values. Thanks @hcirellu.
1. A replacement in an integer64 vector or array using `[<-` 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.
1. `union`, `setdiff`, `intersect`, `setequal` and `is.element` get an
overload to work correctly with `integer64` (#182).
1. The methods of the 'Ops' group (e.g. `+`, `&`, `==`) 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.
1. `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.
## BUG FIXES
1. `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).
1. `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.
1. `log(integer64(), base=integer64(1))` no longer warns, consistent
with `log(integer(), base=integer())` (#93).
1. `sortfin(integer64(), 1:10)` no longer segfaults (#164).
1. `orderfin(as.integer64(10:1), 1:3, 8:11)` enforces that `table` be
sorted by `order` instead of segfaulting (#166).
1. `ordertab()` no longer segfaults when `nunique` is smaller than the actual \
number of unique values (#168).
1. `as.integer64.character` now returns `NA` for out of range values,
with warning, e.g. `as.integer64("22222222222222222222")`
(#175). Thanks @hcirellu.
1. `quicksort()` and others no longer segfault on trivial cases
(e.g. sorting 0 or 1 item, #220).
1. `as.integer64(2^63)` returns `NA_integer64_` more consistently
(e.g. on ARM), consistent with `as.integer(2^31)` (#19). Thanks
@dipterix.
1. `[.integer64` now runs faster and correctly regarding `NA` and
arrays (#176). Thanks @hcirellu.
1. `integer64() %in% 1L` no longer warns (#265). Thanks @hcirellu.
1. `match.integer64(..., method="orderpos")` and
`duplicated.integer64(..., method="orderdup")` no longer fail with
"object 's' not found" (#58).
1. `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.
## NOTES
1. {bit64} no longer prints any start-up messages through an
`.onAttach()` hook (#106). Thanks @hadley for the request.
1. The R version dependency has been bumped from 3.4.0 (2017) to 3.5.0
(2018).
1. From R 4.6.0, R's {utils} package has its own 'bitstring' class
which is basically compatible with that shipped by {bit64} for many
years. `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.
|
Log message:
(devel/R-bit64) Updated 4.5.2 to 4.6.0.1
# bit64 4.6.0-1
## NOTICE OF PLANNED BREAKING CHANGES
1. {bit64} exports many S3 methods directly. Calling S3 methods
directly is generally bad form; we should rely on the S3 dispatch
system for this. Needing to export an S3 method is usually indicative
of some deep issue that's otherwise hard to work around.
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.
1. {bit64} lists {bit} as `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).
## NEW FEATURES
1. Implemented S3 methods for `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.
1. 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).
1. `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!
## BUG FIXES
1. `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.
1. 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.
## NOTES
1. After creating, developing, and maintaining {bit64} for about 13
years, Jens Oehlschlägel has decided to step down as maintainer of the
package. Michael Chirico will take over in this duty. Thank you Jens
for creating such a wonderful & important part of the R ecosystem!
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.
1. The R version dependency has increased from 3.0.1 (May 2013) to
3.4.0 (April 2017). We plan to keep roughly the same R dependency as
{data.table}, i.e., as old as possibly for as long as possible, with
some bias towards gradually bringing in new R features to reduce the
maintenance overhead of a growing nest of workarounds to keep the
package "fresh" for users of the latest R versions.
Required package {bit} already requires R 3.4.0, so the old 3.0.1
requirement was effectively impossible anyway.
1. Default packages {methods}, {stats}, and {utils} are now
`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.
1. 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.
1. 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.
# bit64 NEWS for versions 0.8-3 through 4.5.2 are now in
[NEWS.0](https://github.com/r-lib/bit64/blob/master/NEWS.0)
|