Hi Luke,
In my mind, the number one need for 64-bit integers comes from
interfacing with other applications / programming languages /
serialization formats which themselves use 64-bit integers either by
default, or by convention. I've enumerated some examples below.
- reticulate: NumPy's default integer dtype on Linux/macOS is int64,
and pandas uses int64 for integer columns -- so the common case has no
faithful R representation. reticulate ships opt-in options
(reticulate.long_as_bit64 and friends) because there's no correct
default; users have reported silently altered values when int64
columns round through double (e.g. rstudio/reticulate#729, #323).
Nanosecond timestamps (datetime64[ns], the pandas default) are int64
offsets and lose precision through POSIXct.
- arrow: int64 is ubiquitous in Parquet. The package's compromise is a
global option, arrow.int64_downcast, under which an int64 column
becomes integer or integer64 depending on whether its current values
happen to fit -- the R type is determined by the data's values rather
than its schema.
- DBI backends: BIGINT is the standard type for primary keys. odbc,
RPostgres, RMariaDB, and RSQLite each expose a bigint = c("integer64",
"integer", "numeric", "character") connection argument, and bigrquery
offers the same four choices at download time -- the same
correctness/compatibility trade-off, pushed onto users and
re-implemented per driver.
- JSON APIs: 64-bit identifiers are the norm; jsonlite has
bigint_as_char, and some upstream APIs ship string duplicates of id
fields to route around clients that parse into doubles. JavaScript has
since added BigInt to support such larger integers.
- rJava maps Java long to double; Rcpp/cpp11/extendr users smuggle
int64_t through bit64's bit-packing convention.
Stepping back, part of why this keeps coming up is that int64 has
quietly become the de-facto integer of the serialization layer itself.
Protocol Buffers, Thrift, Avro, FlatBuffers, MessagePack, CBOR, and
BSON all define 64-bit integer types; Parquet's integer physical types
are int32 and int64, and both Parquet and Arrow represent timestamps
as int64 offsets, increasingly at nanosecond resolution; SQLite's
integer value class is a 64-bit signed int.
Best,
Kevin
On Fri, Jul 24, 2026 at 4:38 PM Gabriel Becker <[email protected]> wrote:
>
> Hi Luke,
>
> The one I know of is to allow lossless, direct interface to databases that
> either a) store some data as 64 bit integers, or b) index using 64 bit
> integers due to number of records without needing a glue layer that does a
> bunch of casting (for some value of 'a bunch').
>
> I believe both of the above cases would also assumedly hold for flat
> formats that store things as 64bit ints, or need such for offsetting into
> them due to size, as brought up by Kylie Bemis in the RSMF meeting.
>
> ~G
>
> On Fri, Jul 24, 2026 at 3:27 PM Josiah Parry <[email protected]> wrote:
>
> > Immediately, spatial indices come to mind. H3, S2, A5 are all represented
> > as 64 bit integers.
> >
> > While an unsigned 64 bit integer, this semi-recent conversation shows a few
> > different strategies in {a5r} that were tried
> > https://github.com/belian-earth/a5R/pull/12
> >
> >
> >
> > On Fri, Jul 24, 2026 at 11:25 Ravi Varadhan via R-devel <
> > [email protected]> wrote:
> >
> > > Luke,
> > >
> > > This is an old post from 2015 on R-Bloggers that provided some examples:
> > >
> > > https://www.r-bloggers.com/2015/06/r-in-a-64-bit-world/
> > >
> > > Ravi
> > >
> > > ________________________________
> > > From: R-devel <[email protected]> on behalf of
> > > luke-tierney--- via R-devel <[email protected]>
> > > Sent: Friday, July 24, 2026 14:04
> > > To: [email protected] <[email protected]>
> > > Subject: [Rd] request for use cases for larger integers in R
> > >
> > >
> > > External Email - Use Caution
> > >
> > >
> > >
> > > R integers are current limited to a magnitude ot 2^31 - 1. Integer
> > > values up to a magnitude of 2^53 can be represented exatcly as
> > > doubles. At times it would be useful to be able to handle larger
> > > values.
> > >
> > > Several options for adding support for large integers to R are under
> > > consideration, each with advantages and disadvantages. To help with
> > > deciding how to move forward it would be helpful to have a collection
> > > of use cases where something is either difficult or impossible to
> > > achieve with the current R integer representations. Examples would be
> > > most helpful if they are concrete enough to allow us to build test
> > > cases.
> > >
> > > Thanks,
> > >
> > > luke
> > >
> > > --
> > > Luke Tierney
> > > Professor Emeritus
> > > Department of Statistics and
> > > Actuarial Science
> > > University of Iowa
> > > 241 Schaeffer Hall email: [email protected]
> > > Iowa City, IA 52242 WWW: http://stat.uiowa.edu/<
> > > http://stat.uiowa.edu/>
> > >
> > > ______________________________________________
> > > [email protected] mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel<
> > > https://stat.ethz.ch/mailman/listinfo/r-devel>
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > ______________________________________________
> > > [email protected] mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > [email protected] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
