Duncan, Right now, my package converts 32-bit integer data in doubles and 64-bit integer data into strings. That avoids "casting" INT_MIN into NA or creating a 64-bit double value that is NA. (Sorry about the typo earlier, I meant INT_MIN not -INT_MIN). I've seen other code that holds 64-bit integer data as a pair of doubles to prevent NAs.
My preferred solution would be to create a `raw32` and `raw64` storage modes and have them support (unsigned) arithmetic and binary operations. Of course this would differ from the current raw storage mode that isn't considered a numeric data type, so different names might be needed like `uint` and `ulong`. The alternative solution would be using a value of raw as a storage mode but uses classes to indicate whether arithmetic operations are 8-bit, 32-bit, or 64-bit wide. While this could be done as a package, I assume that doing it in base R would be more efficient and robust. The third option would be what you suggested. Use integer storage mode for 32-bit values, but use a class to tell arithmetic operations to treat INT_MIN as INT_MIN and not NA_integer_. With something equivalent for 64-bit value. All, Here is also another example of where I had to work around NA values at the R level. This code reads values from a specific compressed binary format and INT_MIN values are valid and need to be processed like numbers. This code solved it by specifically testing for NAs and setting them to the corresponding numeric value. https://github.com/reedacartwright/rbedrock/blob/79b576ac47fcf4b55d6d764c5b79d6037e983629/R/blocks.R#L123 This code is no longer used because I found it easier to replace it with C code that didn't need to work around NAs or use the bitops package. Cheers, Reed On Fri, Jul 24, 2026 at 5:21 PM Duncan Murdoch <[email protected]> wrote: > > 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
