[Rd] request for use cases for larger integers in R

[Duncan Murdoch]

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 <gabembecker using gmail.com> 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 <josiah.parry using gmail.com> 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 <
>>> r-devel using r-project.org> 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 <r-devel-bounces using r-project.org> on behalf of
>>>> luke-tierney--- via R-devel <r-devel using r-project.org>
>>>> Sent: Friday, July 24, 2026 14:04
>>>> To: R-devel using r-project.org <R-devel using r-project.org>
>>>> 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:   luke-tierney using uiowa.edu
>>>> Iowa City, IA 52242                 WWW:  http://stat.uiowa.edu/<
>>>> http://stat.uiowa.edu/>
>>>>
>>>> ______________________________________________
>>>> R-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel<
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>>
>>>>          [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> R-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>>          [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> R-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>          [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel