I'm curious about your suggestion that -INT_MIN should not be NA. That
makes sense if you are reading values from a non-R source; then -INT_MIN
should be the value -INT_MIN. So then one question is, how to represent NA?
One way to handle this would be to embed the values in some larger type,
e.g. allow a user to read 32 bit values into double or int64.
Another would be to tell R to pretend there's no such thing as NA, and
all values should be treated as their value according to the same rules
as every other value. (I think this idea would be a nightmare to
implement: it might require two versions of every function that works
with integers.)
Did you have something in mind? If a user tries to read -INT_MIN from a
field declared to be a 32 bit signed integer, what should happen?
Duncan Murdoch
On 2026-07-24 7:59 p.m., Reed A. Cartwright wrote:
My package, rbedrock, reads and manipulates data from external
sources. Some of the data is stored as 64-bit integers, and in order
to not depend on the bit64 package, I store them as strings [1]. Of
course, native support would be helpful for this data type.
Another feature that I would find useful when dealing with external
dataset is to not map -INT_MIN to NA, as a user might need to perform
arithmetic on external data that has that value. Having 32-bit and
64-bit wide binary values that support (unsigned) arithmetic might be
a way to support efficient editing of external data. It would
definitely help me encode certain algorithms at the R level instead of
the C level.
[1] https://github.com/reedacartwright/rbedrock/blob/main/src/nbt.c#L334
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
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
