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 ;-) H.> > 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). > > Dirk >-- Herv? Pag?s 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 at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319
On 16/08/2018 18:33, Herv? Pag?s wrote:> 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 cousinsWell, not all compilers. Those types were introduced in C99, but are optional in that standard and in C11 and C++11. I have not checked C++1[47], but expect they are also optional there. int_fast64_t is not optional in C99, so R uses that if int64_t is not supported. [It is easy to overlook that they are optional in C99 and at one time R assumed them.]>> (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 ;-)R's configure checks that int is 32 bit and will not compile without it (src/main/arithmetic.c) ... so int and int32_t are the same on all platforms where the latter is defined. -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford
On 08/16/2018 11:30 AM, Prof Brian Ripley wrote:> On 16/08/2018 18:33, Herv? Pag?s wrote:...>> >> 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 ;-) > > R's configure checks that int is 32 bit and will not compile without it > (src/main/arithmetic.c) ... so int and int32_t are the same on all > platforms where the latter is defined.Good to know. Thanks for the clarification! -- Herv? Pag?s 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 at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319