[R] double precision
nabble.30.miller_2555 at spamgourmet.com
Wed Aug 19 19:49:52 CEST 2009
Roger Bivand wrote:
> On Tue, 5 Dec 2006, Yoni Schamroth wrote:
>> I am attempting to query a data frame from a mysql database.
>> One of the variables is a unique identification number ("numeric") 18
>> I am struggling to retrieve this variable exactly without any rounding.
> Read it as a character - a double is a double:
>> x <- 6527600583317876352
>> y <- 6527600583317876380
>  TRUE
>  "double"
> and why they are equal is a FAQ (only ~16 digits in a double). Integer is
> 4-byte. Since they are IDs, not to be used for math, leave them as
> character strings - which they are, like telephone numbers.
Resurrecting this post for a moment, the same issue arose when interfacing R
with a Postgres database using the bigint data type (a signed 64-bit integer
ranging from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 as of
this writing). While the underlying cause is summarized above, I'd like to
recommend the inclusion of a 64-bit integer data type into the R base. For
performance reasons, I use R to independently generate a unique transaction
ID that is equivalent to the Postgres-generated bigint (with some
consistency checks -- generally bad design, but vastly quicker than
querying the database for the same value). I currently generate a string
representation and pass that to the DBI, though the process is cumbersome
and likely not as efficient as an arithmetic equivalent (particularly when
using a 64-bit processor architecture). Furthermore, there are additional
gyrations that need to occur when querying the database for bigint values.
Do significant practical challenges exist in the implementation of a 64-bit
integer that would outweigh the faster and cleaner compatibility with
View this message in context: http://www.nabble.com/-R--double-precision-tp7708057p25048915.html
Sent from the R help mailing list archive at Nabble.com.
More information about the R-help