hp@ge@ @ending from fredhutch@org
Thu Aug 16 19:33:15 CEST 2018
On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote:
> On 15 August 2018 at 20:32, Benjamin Tyner wrote:
> | Thanks for the replies and for confirming my suspicion.
> | Interestingly, src/include/S.h uses a trick:
> | #define longint int
> | and so does the nlme package (within src/init.c).
> As Bill Dunlap already told you, this is a) ancient and b) was concerned with
> the int as 16 bit to 32 bit transition period. Ie a long time ago. Old C
> programmers remember.
> You should preferably not even use 'long int' on the other side but rely on
> the fact that all compiler nowadays allow you to specify exactly what size is
> used via int64_t (long), int32_t (int), ... and the unsigned cousins (which R
> does not have). So please receive the value as a int64_t and then cast it to
> an int32_t -- which corresponds to R's notion of an integer on every platform.
Only on Intel platforms int is 32 bits. Strictly speaking int is only
required to be >= 16 bits. Who knows what the size of an int is on
the Sunway TaihuLight for example ;-)
> And please note that that conversion is lossy. If you must keep 64 bits then
> the bit64 package by Jens Oehlschlaegel is good and eg fully supported inside
> data.table. We use it for 64-bit integers as nanosecond timestamps in our
> nanotime package (which has some converters).
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages using fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
More information about the R-devel